home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000068_yackd@alaska.et.byu.edu_Tue Oct 19 14:46 MDT 1993.msg < prev    next >
Internet Message Format  |  1994-10-30  |  12KB

  1. Received: from yvax2.byu.edu by maine.et.byu.edu; Tue, 19 Oct 93 14:46:53 -0600
  2. Return-Path: <yackd@alaska.et.byu.edu>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  4.  <01H4ATPJDNVK94NVUS@yvax.byu.edu>; Tue, 19 Oct 1993 14:44:37 MDT
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  6.  <01H4ATOS2XYO9BWK93@yvax.byu.edu>; Tue, 19 Oct 1993 14:44:00 MDT
  7. Received: from yvax2.byu.edu by alaska.et.byu.edu; Tue, 19 Oct 93 14:44:44 -0600
  8. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  9.  <01H4ATN22IB494NVUS@yvax.byu.edu>; Tue, 19 Oct 1993 14:42:37 MDT
  10. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  11.  <01H4ATMWASO09BWBQS@yvax.byu.edu>; Tue, 19 Oct 1993 14:42:29 MDT
  12. Received: by alaska.et.byu.edu; Tue, 19 Oct 93 14:44:15 -0600
  13. Date: Tue, 19 Oct 1993 14:44:15 -0600
  14. From: yackd@alaska.et.byu.edu (Don Yacktman)
  15. Subject: Comment on the MiscKit license
  16. To: misckit@byu.edu
  17. Message-Id: <9310192044.AA03387@alaska.et.byu.edu>
  18. Content-Transfer-Encoding: 7BIT
  19. Status: RO
  20.  
  21.  
  22. I am forwarding a message to the list, to open a few issues up
  23. for discussion.  (The reason it wasn't posted to the list right
  24. away, and was sent to me first, will be apparent from reading
  25. the message.)
  26.  
  27. My opinions on this:  I think for the most part I agree with
  28. Joe's comments here.  The only one I worry about is the mass
  29. media thing, and here's why... On a media which is sufficiently
  30. large enough to hole the kit uncompressed, I'd prefer the kit
  31. be distributed uncompressed (like a CD-ROM, especially) so that
  32. the user can poke about the kit without having to decompress it,
  33. typically by copying the whole thing off of the media.  It's a
  34. convenience issue, mostly.  I also don't want someone to charge
  35. huge amounts of money for the MiscKit.  The kit is free, and I
  36. don't want someone to come along and, for example, sell the kit
  37. on floppy for $100, and then claim that the kit was free, of
  38. course, but the media cost was $100.  That's just plain obnoxious,
  39. and I know that if we didn't restrict this in some way, it will
  40. happen, and the gullible folk will be taken in...
  41.  
  42. Finally, as to the administrator's permission before distribution
  43. via mass media, there's three things involved:  (1) the distributor
  44. ought to me told/informed of the latest version; they can
  45. distribute whichever version they like, but ought to at least
  46. be given the option of using the latest version; this option
  47. can only be presented if they get the latest release info from
  48. the administrator, since only the administrator knows exactly
  49. when new releases will be made, and also a new release can be
  50. rushed through to make deadlines for the distributor, if need
  51. be.  (2) It allows the administrator to keep track of who is
  52. distributing the MiscKit, so that if someone asks "where can
  53. I get this on CD-ROM?" the administrator can answer...and, in
  54. this case, if there are two or three competing CD-ROM vendors,
  55. if one didn't tell the administrator of their product, it would
  56. give their competitors and advantage, since their name would
  57. not come up as a possible distribution point... and (3) it's
  58. just a common courtesy to let the MiscKit folks know about
  59. redistribution of their work.  Perhaps I should re-word it
  60. that permission is granted as long as they notify the MiscKit
  61. administrator of the re-distribution...
  62.  
  63. Anyway, my comments above will make more sense in light of
  64. the message below, from Joe Grace.  Any comments from other
  65. folks out there?
  66.  
  67. Later,
  68. -don
  69.  
  70.  
  71.  
  72. Begin forwarded message:
  73.  
  74. >From jgrace@TetraSoft.com Tue Oct 19 13:25 MDT 1993
  75. Received: from uucp5.netcom.com by texas.et.byu.edu; Tue, 19 Oct 93 13:25:44 -0600
  76. Return-Path: <jgrace@TetraSoft.com>
  77. Received: from TetraSoft.com by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
  78.     id AA19587; Tue, 19 Oct 93 12:24:33 PDT
  79. Received: by occam.TetraSoft.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  80.     id AA15582; Tue, 19 Oct 93 11:51:37 PDT
  81. Date: Tue, 19 Oct 93 11:51:37 PDT
  82. >From: jgrace@tetrasoft.com
  83. Message-Id: <9310191851.AA15582@occam.TetraSoft.com>
  84. Received: by NeXT.Mailer (1.95)
  85. Received: by NeXT Mailer (1.95)
  86. To: yackd@texas.et.byu.edu (Don Yacktman)
  87. Subject: Re: New MiscKit
  88. Status: R
  89.  
  90. Ok Don,
  91.  
  92. >If I don't get any more feedback on the charter and license
  93. >before Friday, they will become version 1.0, so speak now
  94. >or forever hold your peace!
  95.  
  96. you forced me to do it...  look at the MiscKit license! :-)
  97.  
  98. I have a variety of comments.  If I am too late in the process, or somehow going against the grain of the MiscKit purpose, just let me know.  I am sending this e-mail only to avoid opening a can of worms unnecessarily.
  99.  
  100. As you know, I did not become a member of the MiscKit mailing list until a few weeks ago.  I may have missed some definitive discussions about these topics.  Nevertheless, here's my 2 cents.
  101.  
  102. My comments fall into four categories:  typos and diction, possible simplification, less restriction, and more restriction.
  103.  
  104. 1.  Typos and diction:
  105.  
  106.     I noticed two typos, "conatining" should be "containing", and "peice" should be "piece".  On diction, the term "Indian Giver" is very derogatory (and unfair, I believe) to the American Indian community.  Perhaps, its usage could be avoided (and see #2, just below).
  107.  
  108. 2.  Possible Simplification:
  109.  
  110.     Re: 5bcd
  111.     I think the license could be simplified somewhat by adopting the dual copyright approach to submissions.  As I understand it, when someone submits <something> to the public domain, two identical "version"s of that <something> now exist, one with the original copyright holder's copyright and one in the public domain.  Typically, the original is moribund and the PD version takes over.  However, in theory (and in some practical cases, e.g., JOVE or Josh's Own Version of Emacs), the original author retains a copyrighted version of the material to do with whatever s/he would like.  This dualism avoids any confusion of excluding one party or the other from having "the" official copyright.
  112.     In the case of MiscKit, a copyright would be donated by the author to MiscKit.  Both the author and MiscKit would then have copyrighted versions of identical material for their own purposes.  In this way, the backpedaling ("Indian Giver") problem is avoided.  For example, when I submit an article to NeXT Review, they get certain copyright (i.e., exclusive publication rights for some number of months, and the copyright to reprint), but I retain all my original copyrights (excepting any violation of their temporary exclusive publishing privilege).
  113.     I believe the license could be simplified by adopting this dual copyright model.  For instance, the support issue by author could be dropped (it has no bearing on MiscKit's copyright).  Also, the whole issue of backpedaling could be dropped, except perhaps to mention that the author loses any right over the MiscKit copyright, even if s/he had a change of heart and wanted to reclaim it.  In this case, the author would still retain the original copyright to do with whatever s/he wished, but would have lost ownership and control over the MiscKit copyright'ed version.
  114.  
  115. 3.  Less Restriction:
  116.  
  117. I may have missed important stuff on this topic, but these are my tastes, for what it's worth...
  118.  
  119.     Re: 3a
  120.     Is the administrator's permission requirement really desirable?  The problems I see:
  121.     It's a hassle (no matter how seemingly minor) for all involved and adds a "big brother" feel to the license.
  122.     If the reason really is "to make sure that the latest version of the MiscKit is being distributed", then perhaps *that* should be term 3a instead.  (Also, see just below.)
  123.  
  124.     Re: 3a: "latest version being distributed"
  125.     Is this 'restriction' really desirable?  I can imagine (especially with GNU stuff) *choosing* to distribute an older version for compatibility, robustness, confidence, patch-stability reasons.  Older versions are not necessarily worse than later versions.
  126.  
  127.     Re: 3bc
  128.     Again, are these restrictions on media format necessary and desirable?  Distributors and users probably deserve the credit of the doubt to choose themselves.  Also, if someone violates these restrictions, is this really a battle MiscKit administrators and owners would care to fight to the finish?  Removing these restrictions could simplify the license, increase karma (what's this guy talking about anyway :-), and avoid sour grapes, so to speak.
  129.     Also, the license could then avoid arbitrarily defining what constitutes "mass media" today, when technology is changing very rapidly.  Arbitrary definitions have short, unpleasant lives in these cases.  (Otherwise, we could go bureaucratic and define a "Consumer Storage Index (CSI)" and relate the "mass storage" to the yearly increase in the CSI! :-)  Frankly, I think such arbitrary stuff is best left to Congress (I hope no Congress-people are on this list :-).
  130.  
  131.     Re: 2
  132.     I would prefer partial kit distribution be allowed.  This restriction is purportedly due to section 6, "collection copyright", but, the way I read the license, would really be due to sections 5bcd (though I don't see the explicit connection).  (I.e., having a collection copyright (section 6) does not restrict you from creating yet other collections, even partial ones.)  Smaller objects should still be distributed with the MiscKit license and under the MiscKit terms, though.
  133.  
  134. 4.  More Restriction:
  135.  
  136.     Re: 2
  137.     Perhaps this 'marking' could simply be a requirement to include the MiscKit License Agreement with any and all distributions.  This is the approach GNU takes.  This approach would ensure the 'marking' were comprehensive and not just superficial.
  138.  
  139.     Re: 9
  140.     Perhaps any changes to the license should be restricted in some way to maintain the community "free"dom to use.  Otherwise, the MiscKit license could go proprietary without warning!  (I know, it couldn't happen... but truth is often stranger than fiction, heh? 1/2 :-)  For example, if MiscKit came under exorbitantly expensive legal fire from some *EVIL* entity (e.g., Microsoft(tm) :-), the rights to the MiscKit could be lost without recourse.  The *EVIL* entity would now *own* the MiscKit and could change the license.  Why tempt fate? (:-)
  141.     Also, this safety restriction could avoid contributors having second thoughts about contributing to a library which has an uncertain future.  GNU takes this approach, and I think it's a wise one (even though the GNU license is too restrictive for my tastes).
  142. <<< Depressing mode on :-( >>>
  143.     (Hmm, I guess this issue is related to the dual copyright approach which I recommend above.  Otherwise, the authors would also get sued by *EVIL* entity and would lose rights that way (since MiscKit never really owned any individual copyrights anyhow.)  As long as Congress does not eradicate the "legal" (counterproductive, illegitimate) morass of software patents, hostile lawsuits must not be taken for granted.  (Actually, I'm not sure anything could avoid disaster in the face of a lawsuit, but (I think) it's worth the words to avoid the possibility if at all possible.)
  144. <<< Depressing mode off :-) >>>
  145.  
  146. Harumph (:-).  "Nuf said by me for the moment.
  147.  
  148. Don, if you would like to post this to the list or otherwise open to public discussion, feel free!  I kept it private since it may open a can of worms you would like to avoid, and I may have missed messages where these issues were covered already.  In any case, I hope my comments are helpful!
  149.  
  150. Cheers,
  151.  
  152. = Joe =
  153.